This invention relates generally to the field of computer systems. More particularly, a system and method are provided for securely and automatically provisioning digital certificates.
PKI (Public Key Infrastructure) technology is used to provide verifiable security for digital data. With PKI technology, a person generates or is issued corresponding private and public keys. The private key is a secret (e.g., a large number) known only to that person. The corresponding public key can be made available to the public or specific people with whom the person wants to securely exchange information. The security is verifiable in that a person's public key will only unlock the information if the information was secured with the person's corresponding private key, and vice versa.
Applying a private key to electronic data generates a digital signature, which can be used as a digital guarantee that the data has not been altered. The digital signature is actually an encrypted digest of the data, generated using a one-way hash function. The recipient decrypts the digest that was sent and also re-computes the digest from the received unencrypted data. If the digests match, the data is proved to be intact and tamper free from the sender.
The digital signature thus ensures that the data originated with the entity signing it and that it was not tampered with after the signature was applied. However, the sender could still be an impersonator and not who he or she claims to be. A digital certificate, issued by a trusted Certificate Authority (CA), may be needed to verify that the message was indeed sent by the person or organization claiming to send it. The digital certificate comprises the person's public key and, depending on the nature of the certificate and the level of trust granted the CA, can provide assurance that the public key—and the corresponding private key—belong to the person they are alleged to belong to.
However, some digital certificates can be obtained with little verification of the identity of the obtainor. To illustrate the problem, consider three entities: Entity A (a legitimate user or organization), Entity B (a recipient of a digital signature from an entity purporting to be Entity A) and Entity C (a fraudulent user or organization).
To implement digital signatures it is required that a signer be issued a private key and a corresponding public certificate containing the signer's public key. The signer (Entity A) will make use of his private key to digitally sign a document, with the recipient (Entity B) using Entity A's public certificate to verify the signature.
It is vital that the recipient of the signature (Entity B) be very sure that the certificate used for verification is the bona fide certificate belonging to Entity A. If another entity (Entity C) manages to get Entity B to believe that her (Entity C's) own certificate belongs to Entity A, then Entity C can effectively forge Entity A's signature (at least well enough to fool Entity B).
Compounding this issue is the scenario where Entity B is an organization that wishes to issue certificates to its employees (e.g., Entity A). Entity B needs some way of confirming that the private key was successfully received by Entity A and not by Entity C (for example, an unscrupulous co-worker), otherwise Entity C could forge Entity A's signature.
There are various schemes for dealing with these issues, usually involving some sort of network of trust. One example includes Entity A being responsible for acquiring his own key, and then passing along the public certificate in person (or by some other secure method that ensures identity) to a representative of Entity B, which can then ensure that the certificate is bona fide. This method can be cumbersome, however, particularly if Entity A is not technically (and security) savvy.